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THE  FOUR  FORMS  OF  Q 

Alternate  Syntactic  Forms  for  an  Object-Oriented  Language 

Bruce  J.  MacLennan 

Computer  Science  Department 

Naval  Postgraduate  School 

Monterey,  CA  93943 

1.    Introduction 

In  this  report1  we  describe  four  alternative  syntactic  forms  for  the  object-oriented  language  ft,  described  in 
our  View  of  Object-Oriented  Programming  (Naval  Postgraduate  School  Computer  Science  Dept.  Tech. 
Rept.  NPS52-83-0O1,  Feb.  1983).  Additional  information  on  a  prototype  implementation  of  ft  can  be 
found  in  Heinz  M.  McArthur's  Design  and  Implementation  of  an  Object-Oriented,  Production- Rule  Inter- 
preter (Naval  Postgraduate  School  Master's  Thesis,  Dec.  1984). 

It  must  be  emphasized  that  these  notations  are  all  different  concrete  representations  for  the  same 
abstract  language.  Thus,  for  example,  rules  could  be  entered  in  one  form  and  displayed  in  another.  This 
permits  different  U3ers  (or  the  same  user  at  different  points  in  time)  to  look  at  a  program  in  different 
ways. 

The  first  syntactic  form,  ftlf  uses  a  predicate  logic  style.  It  is  also  the  simplest  to  parse.  The  second 
and  third  styles  (ft3  and  fts)  have  a  stylized  natural  language  format.  As  a  result  they  are  less  compact, 
but  more  readable  to  computer-naive  users.  The  fourth  form,  ft4,  drops  the  linear  syntax  of  the  other 
three,  and  adopts  a  two-dimensional  format  based  on  the  idea  of  a  form.  It  is  the  least  compact,  but  most 
amenable  to  use  by  computer-naive  users. 

We  describe  each  of  these  forms  in  the  body  of  this  report,  and  illustrate  the  forms  with  a  simple 
example.    A  formal  grammar  for  each  format  appears  in  the  Appendices. 


1.    Work  reported  herein  wu  supported  in  part  by  the  Office  of  Naval  Research  under  contract  number  N00014-85-24057. 
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3.    First  Form 

The  first  form,  H,  is  based  on  a  predicate-logic  style  notation.  It  will  look  familiar  to  readers  acquainted 
with  logic  programming  languages  and  production  rule  systems.  The  basic  construct  is  the  rule,  which 
has  the  form 

cause     =>     tfjtct 

The  cause  describes  a  possible  situation  in  a  space  of  objects  connected  by  relations.  If  that  situation 
holds,  then  the  rule  may  be  applied,  which  means  that  the  actions  described  by  its  effect  part  will  be  per- 
formed. Rules  are  executed  indivisibly,  which  means  that  it  is  guaranteed  that  the  situation  still  holds 
when  the  actions  are  performed. 

There  is  normally  no  order  implied  between  rules;  they  can  be  tested  in  any  order.    However,  rules  can 
be  connected  by  the  word  else  when  a  particular  order  must  be  imposed: 

cause  i    =s>    effectx 
else  cause  2    =>    effect? 

else  eausen     =>    effectn 

In  this  case,  the  second  and  succeeding  rules  are  tried  only  when  the  preceding  rules  have  failed. 

The  cause  part  of  a  rule  describes  a  situation  in  terms  of  one  or  more  conditions,  which  represent  the 
presence  or  absence  of  relationships  between  objects: 

condition  ,,  condition^,  ■  ■  ■  ,    conditionn 

All  of  these  conditions  must  be  satisfied  before  a  rule  can  be  applied. 

A  condition  for  testing  for  the  presence  of  a  tuple  in  a  relationship  has  the  form: 

primary   (  pattern  x,  pattern 2,  •  ■  ■  ,    patternn   ) 

The  primary  is  an  expression  (usually  just  an  identifier)  that  evaluates  to  a  relation.  The  following  list  of 
patterns  defines  a  tuple  pattern.  Each  pattern  in  the  list  can  be  either  an  free  (i.e.,  undefined)  variable,  or 
an   expression  containing   no  free   (i.e.,   only   bound)   variables.     An   expression   is  evaluated   during  the 


matching  process,  and  matches  a  value  equal  to  the  result  of  its  evaluation.  A  free  variable  will  match 
any  value,  but  becomes  bound  to  that  value  during  the  matching  process.  The  special  free  variable  '— ' 
can  be  used  to  match  anything  without  binding  a  variable  name. 

A  condition  for  testing  for  the  absence  of  a  tuple  from  a  relationship  has  the  form: 

->  primary   (  pattern  u  pattern  2,  .  .  .  ,    patternn   ) 

This  condition  succeeds  only  if  there  is  not  a  tuple  of  the  specified  form  in  the  relation  that  is  the  value  of 
the  primary. 

Finally,  as  a  convenience  we  permit  cancel  conditions: 

'primary   (  pattern ,,  pattern 2;  .  .  .  ,    pattern,,   ) 

This  tests  for  the  presence  of  a  tuple  of  the  specified  form,  just  as  the  first  kind  of  condition,  but  it  has  a 
side  effect  of  deleting  that  tuple  if  the  rule  is  applied.  Although,  this  could  be  programmed  explicitly,  the 
situation  is  common  enough  that  it  is  important  to  reflect  it  in  the  notation. 

The  effect  part  of  a  rule  is  composed  of  a  sequence  of  transactions: 

transaction |,  transaction2,  ■  ■  ■  ,    transactionn 

These  transactions  can  be  performed  in  any  order  or  in  parallel.  The  transactions  are  of  four  kinds:  asser- 
tions, denials,  calls  and  sequential  blocks. 

An  assertion  is  a  transaction  of  the  form: 

primary  (  expression  u  expression  2,  .  .  .  ,    expressionn  ) 

Its  effect  is  to  add  to  the  relation  that  is  the  value  of  the  primary  the  tuple  <  Vlt  V2,  .  .  .  ,  Vn>,  where 
each  V,  is  the  value  of  expression, .  Typically  these  expressions  contain  variables  that  were  bound  in  the 
cause  part  of  the  rule. 

A  denial  has  the  form  of  an  assertion  preceded  by  a  negation  sign: 

-> primary  (  expression  it  expression 2,  .  .  .  ,    expression^  ) 

Its  effect  is  to  delete  the  specified  tuple  from  the  specified  relation.    If  this  relation  does  not  contain  this 
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tuple,  then  an  error  condition  holds. 

A  call  is  a  transaction  of  the  form: 

primary   {  expression ,,  expression  2,  •  •  ■  ,    expression,,   } 

Its  purpose  is  a  form  of  synchronous  communication  performed  by  sending  a  message  through  one  relation, 
and  waiting  for  a  reply  to  be  returned  through  another  relation.    For  example,  the  call 

P{E,F) 

has  the  effect  of  performing  the  assertion 

P(*,E,F) 

Here  a  is  a  newly  generated  relation  that  will  be  used  for  receiving  the  reply.  This  assertion  presumably 
requests  some  actions  to  be  performed  by  other  rules  (which  are  watching  P).  When  the  actions  are  com- 
pleted, an  acknowledgment  or  reply  will  be  placed  in  the  a  relation,  which  permits  the  calling  rule  to 
complete.    Note  that  rules  containing  calls  in  their  effect  parts  are  not  considered  indivisible. 

The  last  kind  of  transaction  is  a  sequential  block,  which  has  the  form: 

{  statement jj  statement 2;    •  •  ■  ;  »tatementn   } 

The  effect  of  this  construct  is  to  execute  the  component  statements  in  order.  A  statement  is  simply  a 
rule,  simple  or  compound,  with  the  additional  characteristic  that  its  cause  part  (and  the  =>)  can  be  omit- 
ted. This  reflects  the  fact  that  in  a  sequential  block  the  performance  of  actions  may  be  conditioned  solely 
on  the  performance  of  the  preceding  statements. 

A  user  normally  interacts  with  an  ft  system  by  typing  statements.    Thus  the  form  of  an  ft  terminal 
session  is: 

statement  x; 
statement  2, 

statementn  ; 
Many  of  the  statements  typed  interactively  are  isolated  effects  containing  a  single  call.    For  example,  to 


define  'Contents'  to  be  a  new  private  relation,  a  user  would  enter: 

Define{  Private,  ,!Contents",  NewRel{}  }; 

Finally,  we  need  a  means  for  manipulating  groups  of  rules  as  a  unit;  this  is  the  rule  denotation  and  has  the 
form: 

«  compound  —  rule  t.  compound  —rule 2.    '  "  '    compound  —rulen  .  » 

Notice  that  each  compound  rule  is  terminated  by  a  period.    (A  compound  rule  is  simply  a  rule  that  may 
contain  elses.) 

There  follows  an  Qi  session  to  declare  an  abstract  type  manager  for  stacks.  The  first  group  of  com- 
mands defines  the  relations  that  characterize  stacks.  Next  comes  a  rule  denotation  containing  the  rules 
for  managing  stacks.  Finally,  a  group  of  definitions  make  certain  of  the  relations  public,  but  with  res- 
tricted capabilities. 


STACKS  IN  n, 

Define  {Private,  "Contents",  NewRel{}}; 
Define  {Private,  "Push",  NewRel{}}; 
Define  {Private,  "Pop",  NewRel{}}; 
Define  {Private,  "Destroy",  NewRel{}}; 
Define  {Private,  "NewStack",  NewRel{}}; 

Define  {Private,  "Rules", 
«*Push(,4  ,X,S),  *Contents(y,5)    =>    Receives(yi  ,5  ),  Contents(cons[X  ,  Y  ],  5  ). 

*Pop(A  ,5),  *Contents( X  ,S  )    =>    Receives(yi  ,first[.Y  ]),  Contents(rest[A"  ],S  ). 

*NewStack(y4  ),  *Avail(S)    =*    Receives(,4  ,5),  Contents(nil,5). 

*Destroy(^4  ,5),  *Contents(Jf  ,5  )    =>    Receives(.A  ,X).  »  }; 
Activate  {Rules}; 

Define  {Public,  "Push",  AddOnly{Push}}; 
Define  {Public,  "Pop",  AddOnly{Pop}}; 
Define  {Public,  "Destroy",  AddOnly{Destroy}}; 
Define  {Public,  "NewStack",  AddOnly{NewStack}}. 

S.    Second  Form 

The  second  form  of  fi  attempts  to  achieve  a  more  natural  notation  by  permitting  relations  to  be  named 
by  templates.    For  example,  we  can  denote  the  Contents  relation  by  the  template: 

—  is  contents  of  — 

Then,  instead  of  using  the  notation  'Contents(.Y  ,5)',  we  can  write  'X  is  contents  of  5  '.  Using  the  more 
mnemonic  'list'  and  'stack'  in  place  of  'X  '  and  '5'  yields  'list  is  contents  of  stack'.  Finally,  fl2  promotes 
readability  by  allowing  the  use  of  "noise  words": 

a  list  is  the  contents  of  the  stack 

Here,  'a'  and  'the'  are  noise  words  inserted  to  improve  the  continuity  of  the  clause. 
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Relations  that  are  intended  to  be  called  as  procedures  should  have  'does'  as  the  first  word  in  their  tem- 
plate.   For  example,  the  template  for  the  Push  relation  is: 

—  does  push  —  on  — 

Inquiries  and  assertions  to  this  relation  are  made  in  the  usual  way,  by  filling  in  the  blanks: 

the  agent  does  push  the  thing  on  the  stack 

However,  the  relation  can  be  called  synchronously  by  omitting  the  first  argument  and  the  word  'does' 
(thus  converting  the  declarative  into  an  imperative): 

push  the  thing  on  the  stack 

This  is  analogous  to  the  Qt  notation 

Push  {thing,  stack} 

which  is  equivalent  to 

Push  (agent,  thing,  stack) 

Templates  that  do  not  begin  with  'does'  cannot  be  called  as  procedures. 

An  inquiry  or  assertion  is  negated  by  placing  the  word  'not'  after  the  first  word  in  the  template,  for 
example, 

the  list  is  not  the  contents  of  the  stack 

The  same  rule  applies  to  'does'  templates: 

the  agent  does  not  push  the  thing  on  the  stack 

The  structure  of  rules  in  fi2  is  the  same  as  in  fy,  except  that  all  rules  are  preceded  by  'When'  and  the 
word  'then'  replaces  the  arrow  '=>'.  The  VI 1  cancellation  symbol,  '*',  is  replaced  by  the  word  'given'  in 
f)2.    In  other  respects  the  syntax  of  fi2  closely  follows  that  of  fi|. 
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STACKS  IN  n2 

Define  private  name  "—  is  contents  of  — "  to  be  make  new  relation; 
Define  private  name  "—  does  push  —  on  — "  to  be  make  new  relation; 
Define  private  name  "—  does  pop  — "  to  be  make  new  relation; 
Define  private  name  "—  does  request  a  new  stack"  to  be  make  new  relation; 
Define  private  name  "—  does  destroy  — "  to  be  make  new  relation; 

Define  private  name  "Stack  Rules"  to  be 
the  rules 
When  given  an  agent  does  push  a  thing  on  a  stack 

and  given  a  list  is  the  contents  of  the  stack 
then  the  agent  does  receive  the  stack 
and  the  appending  of  the  thing  and  the  list 
is  the  contents  of  the  stack. 

When  given  an  agent  does  pop  a  stack 

and  given  a  list  is  the  contents  of  the  stack 
then  the  agent  does  receive  the  first  element  of  the  list 

and  the  rest  of  the  list  is  the  contents  of  the  stack. 

When  given  an  agent  does  request  a  new  stack 

and  given  a  thing  is  available 
then  the  agent  does  receive  the  thing 

and  nil  is  the  contents  of  the  thing. 

When  given  an  agent  does  destroy  a  stack 

and  a  list  is  the  contents  of  the  stack 
then  the  agent  does  receive  the  list. 

end  rules; 
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Activate  the  Stack  Rules; 

Define  public  name  "—  does  push  —  on  — " 

to  be  an  add  only  version  of  "—  does  push  —  on  — "; 
Define  public  name  "—  does  pop  — " 

to  be  an  add  only  version  of  "—  does  pop  — "; 
Define  public  name  "—  does  request  a  new  stack" 

to  be  an  add  only  version  of  "—  does  request  a  new  stack"; 
Define  public  name  "—  does  destroy  — " 

to  be  an  add  only  version  of  "—  does  destroy  — ". 

4.    Third  Form 

The  f)8  syntax  makes  an  additional  step  in  the  direction  of  a  more  natural  notation:  the  provision  of  ana- 
phoric reference.  To  explain  this  we  need  some  grammatical  terminology.  First,  phrases  which  denote  a 
value  or  object,  such  as 

a  list 

a  brother  of  Joe 

the  owner  of  the  file 

something  which  is  moving 

that  which  receives  the  result 

are  called  noun  phrases.  Second,  phrases  that  describe  a  state,  condition  or  relation,  and  normally  stand 
after  a  form  of  the  verb  to  be,  such  as 

hot 

less  than  100 

between  20  and  50 

are  called  adjective  phrases.  Finally,  phrases  that  describe  a  state,  condition,  relation  or  action,  and  either 
do  not  contain  a  form  of  to  be,  such  as 


moves 

does  pop  the  stack 

does  not  push  the  object  on  the  stack 

connects  the  terminal  to  the  processor 

or  contain  a  form  of  to  be  followed  by  a  noun  or  adjective  phrase,  such  as 

is  a  list 

is  less  than  100 

is  not  the  brother  of  Joe 

is  something  which  is  moving 

are  called  verb  phrases. 

A  few  simple  examples  will  illustrate  the  idea  of  anaphoric  reference.    Suppose  that  we  have  the  fol- 
lowing inquiries  in  the  cause  part  of  a  rule: 

T  is  a  terminal    and    T  is  available 

Anaphoric  reference  permits  this  to  be  written 

a  terminal  is  available 

The  indefinite  determiner  la'  before  the  noun  'terminal'  implies  an  inquiry  of  the  form  '  T  is  a  terminal'. 
Furthermore,  the  use  of  the  phrase  'a  terminal'  in  the  clause  'a  terminal  is  available'  implies  that  it  is  the 
same  terminal  T  that  is  available.  In  essence  use  of  the  phrase  'a  terminal'  implies  the  existence  of  an 
object  or  value  X  having  the  property  ' X  is  a  terminal'. 

More  specifically,  the  indefinite  determiners  'a'  and  'an'  before  a  noun  N   are  equivalent  to  X    and 
generate  an  inquiry 

A'  is  TV 

Thus,  the  clause  'an  N  VP',  where  VP  is  a  verb  phrase,  reduces  to  the  two  clauses  'X  is  N  and  X  VP'. 
The  same  rule  applies  even  if  the  noun  is  followed  by  arguments.    For  example,  the  inquiries 

A'  is  a  brother  of  John  and  X  is  moving 
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can  be  written 

a  brother  of  John  is  moving 

Note  that  anaphoric  reference  requires  f)s  to  distinguish  between  nouns,  adjectives  and  verbs. 

We  turn  to  a  more  complicated  example.    Suppose  we  have  the  inquiries: 

T  is  a  terminal  and  T  is  available  and  T  is  not  broken 

Anaphoric  reference  permits  this  to  be  written: 

a  terminal  is  available  and  the  terminal  is  not  broken 

The  use  of  the  definite  determiner  'the'  in  the  phrase  'the  terminal'  guarantees  that  the  terminal  in  ques- 
tion is  the  same  one  referred  to  earlier  in  the  rule. 

Definite  determiners  are  also  permitted  in  the  effect  parts  of  rules.    For  example,  the  rule 

When   T  is  a  terminal  and  given  T  is  available  then   T  is  allocated. 

can  be  written 

When  given  a  terminal  is  available  then  the  terminal  is  allocated 

The  phrase  'the  terminal'  in  the  effect  part  refers  to  the  same  terminal  mentioned  in  the  cause  part. 

Finally,  Q3  provides  a  limited  ability  for  subordination.    For  example,  the  inquiries 

X  connects  the  terminal  to  the  processor  and  X  is  not  busy 

can  be  written 

something  which  connects  the  terminal  to  the  processor  is  not  busy 

In  general,  if  VP  is  a  verb  phrase,  then  the  clause  'something  which  VP'  is  equivalent  to  X  and  generates 
an  inquiry  of  the  form  'X  VP'.    In  other  words,  the  clause 

something  which  VP  VP' 

reduces  to  the  two  clauses 

X  VPand  X  VP' 
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Similarly,  the  phrase  'that  which  VP'  refers  back  to  something  X  in  a  previous  inquiry  of  the  form  lX 
VP'.  Indeed,  the  phrase  'a/an  NP'  can  be  considered  an  abbreviated  form  of  'something  which  is  NP', 
and  'the  NP'  can  be  considered  an  abbreviated  form  of  'that  which  is  NP'. 

Another  permitted  form  of  subordination  is  illustrated  by  the  following  example.    The  inquiries 

a  channel  is  connected  to  a  device  and  the  device  is  not  busy 

can  be  written 

a  channel  is  connected  to  a  device  which  is  not  busy 

In  general  the  phrase  'NP  which  VP'  is  equivalent  to  NP,  but  generates  the  additional  inquiry  'NP  VP'. 
The  use  of  anaphoric  reference  and  subordination  eliminates  almost  entirely  the  need  for  variable  names  in 
rules. 

The  stack  example  is  almost  identical  in  H2  and  fis: 

STACKS  IN  n, 

Define  private  noun  "contents  of—"  to  be  make  new  relation; 
Define  private  verb  "does  push  —  on  — "  to  be  make  new  relation; 
Define  private  verb  "does  pop  — "  to  be  make  new  relation; 
Define  private  verb  "does  request  new  stack"  to  be  make  new  relation; 
Define  private  verb  "does  destroy  — "  to  be  make  new  relation; 

...  remainder  as  in  fl2  ... 

5.    Fourth  Form 

The  two-dimensional  fl  syntax,  Vl4,  is  based  on  the  idea  of  forms.  These  can  be  thought  of,  and  are 
displayed  like,  paper  forms  with  fields  that  can  be  filled  in  with  values.  In  particular,  a  relation  is  con- 
sidered to  be  a  blank  form  (i.e.,  a  template),  and  each  tuple  in  a  relation  is  considered  to  be  a  filled  out 
instance  of  that  form. 

Users  can  explicitly  create  or  delete  form  instances,  that  is,  add  or  delete  tuples  to  or  from  relations, 
by  selecting  a  form  name  (relation  name)  from  a  menu  and  filling  in  the  fields  of  the  form.    This  is  a  very 
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natural  mode  of  operation  for  offices  and  similar  environments.     To  demonstrate  this,  we  use  a  form- 
oriented  terminology  to  describe  the  syntax  of  Q4. 

A  rule  is  represented  by  a  rule  window  labeled  with  the  rule's  name: 


If  the  rule  is  part  of  a  compound  rule,  then  the  right  half  of  the  rule's  title  chains  to  the  alternative  rule 


rule    name  j 

else:  rule    name2 

rule    name  2 

else:  rule    name$ 

Each  rule  window  is  divided  into  two  frames,  an  upper  situation  frame  (the  cause)  and  a  lower  action 
frame  (the  effect): 


name 


situation 


action 


The  situation  frame  is  occupied  by  zero  or  more  condition  panes,  which  represent  the  presence  or  absence 
of  form  instances  (tuples  in  relations).    A  condition  pane  has  tt  le  format: 
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relation  name 


field—  name  |i  field—  pattern  x 
field-  name  2:  field— pattern 2 

field—  namen  :  field—  pattern n 


This  kind  of  condition  pane  tests  for  the  presence  of  the  specified  form  instance  (tuple). 

The  field- patterns  can  be  either  constants  or  variables.  If  they  are  constants  then  the  pane  will  only 
match  a  form  instance  in  which  that  field  is  filled  in  with  that  value.  If  the  field-pattern  is  a  variable, 
then  the  variable  can  be  either  unbound  or  bound.  If  it  is  unbound,  then  it  will  match  any  field-value, 
and  will  become  bound  to  that  field-value.  If  it  is  bound,  then  it  matches  only  the  value  to  which  it  is 
bound.  Field-patterns  can  be  left  blank,  which  has  the  effect  of  filling  them  in  with  new,  unique,  unbound 
variables.    Thus,  blank  field-patterns  are  considered  "don't  cares"  since  they  match  anything. 

The  absence  of  a  form  instance  is  indicated  by  appending  the  modifier  '(absent)'  to  the  form  (rela- 
tion) name: 


relation   name     (absent) 


field- name  x:  field—  pattern  j 
field-  name  2:  field—  pattern 2 

field—  name„  :  field—  patternn 


Similarly,  to  test  for  the  presence  of  a  form  instance,  and  delete  the  form  instance  when  found,  we  append 
the  modifier  '(delete)': 
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relation    name     (delete) 


field—  name  |i  field—  pattern  l 
field—  name  ,:  field-  pattern 2 

field-  namen  :  field-  patternn 


Finally,  there   is  a  special  condition  pane,  called  a  constraint  pane,  which  can  appear  in  the  situation 
frame: 


Constraint 


Boolean   expression 


There  can  be  any  number  of  constraint  pane  in  the  situation  frame;  they  must  all  evaluate  to  true  for  the 
rule  to  apply. 

The  action  frame  is  filled  with  a  number  of  transaction  panes.    A  transaction  pane  can  have  four  for- 
mats: creation,  deletion,  procedure,  or  sequential  process.    A  creation  pane  has  the  form: 


relation  name 


field-  name  t:  field—  value  j 
field—  name  2:  field—  value  2 

field—  namen  :  field—  value „ 


This  calls  for  the  creation  of  the  specified  form  instance.    The  field- values  are  expressions  used  to  compute 
the  values  for  the  fields. 
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A  deletion  pane  calls  for  the  deletion  of  the  specified  form  instance: 


relation    name     (delete) 


field—  name  (:  field—  value  j 
field—  name  2:  field-  value  2 

field—  namen  :  field-  value n 


The  third  kind  of  action  pane  is  a  procedure  or  call  pane- 


relation   name     (procedure) 


field-  name  (:  field-  value  i 
field-  name  2:  field-  value  2 

field-  namen  :  field—  value n 


This  calls  for  a  synchronous  call  of  the  specified  relation.  That  is,  the  form  instance  is  created,  which 
requests  some  action  to  be  performed.  The  rules  containing  the  procedure  call  is  not  considered  complete 
until  the  completion  of  the  requested  action  is  acknowledged  via  an  'Acknowledgement'  form. 

The  last  kind  of  transaction  pane  is  a  sequential  process  pane: 


Sequence 


statement  l 
statement^ 

statement* 


The  statements  are  executed  in  the  order  listed.    They  may  be  either  the  names  of  rule  windows,  or  Q 
rules  in  one  of  the  linear  forms  (fti,  ft2,  or  fts). 

Finally,  we  need  a  means  for  manipulating  groups  of  rules  as  a  unit;  this  is  the  rule-group  window: 
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Rules:  group    name 

rule 

—  name  j 

rule 

—  name  j 

rule 

—  namen 

For  example,  a  request  to  activate  a  rule  group  will  activate  all  the  rules  named  in  that  group. 


A  specification  of  the  stack  example  in  Q4  follows. 
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STACKS  IN  n4 


Rules:    Stack  Rules 


Push  Rule 

Pop  Rule 

New  Stack  Rule 

Destroy  Stack  Rule 


Push  Rule 

Push  Request  (delete) 

Stack  Contents  (delete) 

From:  A 
Item:  X 
Stack:  S 

Stack:  S 
List:  Y 

Acknowledgement 

Stack  Contents 

To:  A 

Concerning:  S 

Stack:  S 

List:  appending  of  X  and  Y 

Pop  Rule 

Pop  Request  (delete) 

Stack  Contents  (delete) 

From:  A 
Stack:  S 

Stack:  S 
List:  X 

Acknowledgement 

Stack  Contents 

To:  A 

Concerning:  First  of  X 

Stack:  S 
List:  rest  of  X 
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New  Stack  Rule 

New  Stack  Request  (delete) 

Available  Object  (delete) 

From:  A 

ID:  S 

Acknowledgement 

Stack  Contents 

To:  A 
Concerning:  S 

Stack:  S 
List:  nil 

Destroy  Stack  Rule 

Destroy  Stack  Request  (delete) 

Stack  Contents  (delete) 

From:  A 
Stack:  S 

Stack:  S 
List:  X 

Acknowledgement 

To:  A 
Concerning:  X 

Dialog 

27: 

Activate  Stac 

k  Rules; 

28: 

Define  public 

Push  Request  to  be 

create-only  Push  Request; 

29: 

Define  public 

Pop  Reque 

st  to  be  create-only  Pop  Request; 

SO: 

Define  public 

Destroy  Sti 

ick  Request  to  be  create-only  Destroy 

Stack  Request; 

31: 

Define  public 

New  Stack 

Request 

to  be  create-only  New  Stack 

Request; 

32: 

— 
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APPENDIX  A:  ABSTRACT  SYNTAX  OF  U 


Session     =     statement  —  list 

statement  —list     =     <8tatement-list;  statement  ;  statement  —list?  > 
/"nil  "\ 


statement  —  list?     = 


statement  —list) 


statement 


(: 


else;  rule  ;  statement  >} 
rule;  cause?  ;  effect?  >  I 


compound —  rule     =     <cpd;  rule  ;  statement?  > 
nil  \ 


statement     — 


stattnent 


< 


rule     =    <rule;  cause  ;  effect?  > 
cause     =    <cause;  condition;  cause?  > 
/'nil     ^1 


cause 


?     = 


cause 


condition     = 


<present;  inquiry  > 
< absent;  inquiry  > 
<cancel;  inquiry  > 


inquiry     =     <inquiry;  primary  ;  tupl  -pattern  > 


tupl  —pattern     - 


tupl  —pattern?     = 


<tupl;  pattern  ;  tupl  -pattern?  >| 
<arbtupl;  pattern  ;  pattern  >        I 

|n„  | 

I  tupl  —pattern) 


pattern     = 


free- variable 


effect?     = 


free- variable) 
expression     J 


nil 

<var;  string  > . 


nil     J 

effect) 


effect    -     <efiect;  transaction;  effect?  > 


transaction     - 


<assert;  predication  > 

<deny;  predication  > 

call 

seq  —block 


V 


predication     =     <predication;  primary  ;  arguments?  > 


/nil 


arguments?     =     ^ 

"  I  arguments! 

arguments     =     <arguments;  expression;  arguments?  > 

call     =     <call;  primary ;  argument?  > 

seq  -block     =     <seq-block;  «<atemen< —/»'«<  > 


/ 


expression 


<binop  ;  expression  ;  expression  > 

<unop  ;  expression  > 

primary 


binop     = 


\ 


or 

and 

eq 

ne 

It 

gt 
le 

ge 

sum 

dif 

prd 

quo 

mod 


V 


/ 


unop 


not) 

negj 


primary     = 


<con;  value  > 

<8elfref;  var  > 

<var;  string  > 

<apply;  var  ;  arguments  > 

<eval;  expression  ;  expression  > 

list 

call 

<rule  — den;  statement  —list  >    , 


list     = 


listing     = 


\ 

listing 

<cons;  expression  ;  expression 

nil  1 

<\ist;expression  ;  listing  >J 


.) 
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APPENDIX  B:    SYNTAX  OF  n, 


Session     —     statement  —  list    . 
statement  —  list     =     statement   ; 


statement 


rule    else  statementy 
[cause    =>]  effect      I 


compound —  rule     =     rule    [  else  statement 
rule     =     cause    =*  effect 
cause     -     [if]  condition   ,    •  •  • 


condition     = 


inquiry 


inquiry     =     primary   (  tupl  —  pattern 
pattern   ,    •  •  ■ 


tup/  —pattern     = 


pattern   :  pattern) 


pattern 


free-variable\ 
expression    J 


free- variable    = 


I  variable) 


effect    =     [transaction 
( 


transaction     -    ' 


assertion 

denial 

call 

seq  -block 


) 


assertion     -     predication 

denial     -     ->  predication 

predication     -     primary   (  arguments   ) 

call     =     primary   {  arguments    } 

arguments     —     [expression   ,    '  '  '  ] 

seq -block     =     {  statement  —  list    } 

expression     =     [expression   V   ]  conjunction 

conjunction     =     [conjunction   AM-1]  relation 
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relation     -     [simplex   relator  ]  simplex 

relator     =     {=|^|<|>|<|^} 
simplex     -     [simplex   {+ \  — }]  term 
term     =    [term   {*  \  /   [  %}}  factor 


factor   = 


+ 


primary 


primary     =     primitive    \:  primary] 

( 
constant 

[@  ]  variable 

primitive    [  arguments 

primitive     =        (  expression   ) 

j  expression   ,    •  •  ■ 
'  1  expression   :  expression 

call 

rule  —denotation 


} 


constant     = 


digit  + 

(char] 
■-) 

nil 


rule  —denotation     =     «  {  compound  —rule    .  }     » 
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APPENDIX  C:    SYNTAX  OF  Q, 


Session     =     statement  —  list    . 
statement  —list     -     statement   ;    •  •  • 

(rule    else  statement^ 
[cause   then]  effect) 

compound  —  rule     —     rule    [  else  statement 

rule     =     cause   then  effect 

cause     =     When  condition  and    ■ 

condition     =     [given]  inquiry 


(word   [not]  \ 

H  [       tl  A)   word      |*UP'  —pattern 

(free-variable\ 
primary        j 

(anything^ 
variable     J 

(pattern   {word  +  pattern)    \ 
arbitrary  pattern  J 


pattern 


variable      \ 
expression) 


noise  -  word     =     {  a    |    an   |    the  } 
{transaction  and    ■  •  •  1 


effect 


/ 


transaction     -    ' 


predication 

call 

seq  —block 


(word  [not]  \  , 

,         i.i  .j  word     [arguments 

call     =     [noise  —word[  word*  [arguments  [ 
arguments     =     expression   {word*  expression) 
seq  —block     =    begin  statement  -  list  end 
expression     =     [expression   or]  conjunction 
conjunction     =     [conjunction   &[  [not]  relation 
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relation     =     \eimplez   relator  ]  simplex 

relator     =     {=|^|<|>|<|^} 
simplex     =     [simplex   {+  \  —  }]  term 
term     =     [term   {*  |  /    |   %}]  factor 


factor   = 


+ 


primary 


primary     -     primitive    \:  primary 
( 


primitive 


constant 
[own]  variable 
word*  of  arguments 
(  expression   ) 

(expression   ,    •  •  ■ 
expression  append  expression] 
call 
rule  —denotation 


constant 


digit  + 

(char 
■-) 

nil 


rule  —denotation     =    rules  {  compound  —rule    .  }     end  rules 


-25- 


APPENDIX  D:    SYNTAX  OF  Q, 


Session     =     statement  —  list    . 
statement  —  list     =     statement   ;    •  •  • 

(rule    else  statement) 
[cause   then    effect  J 

compound  —  rule     -     rule    [  else  statement 

rule     -     cause   then  effect 

cause     -    When  condition   and    ■  •  ■ 

condition     -     [given]  inquiry 

inquiry     =     noun  —phrase    verb  -phrase 

( 


noun  -phrase     = 


determ    noun   arguments    {which  verb  —phrase 

/that  ^ 

\  something/  which  verb  ~Phrase 


verb  —phrase     = 


expression 

verb    [not]  arguments 
does  [not]  verb   arguments 

noun  -phrase) 


is  not 


V 


adj  -phrase 
ad j  —  phrase     =     adjective    arguments 


I 


{prep  -phrase  \ 

arbitrary  variable) 

prep— phrase     =     \preposition]  noun— phrase 

effect    =     [transaction  and    ■  •  •  ] 


transaction     =    ' 


declaration] 

call 

seq  —  block 


declaration     =     noun  -phrase    verb  -phrase 
call     =     verb    arguments 

seq -block     =     begin  statement      list    end 
expression     =     [expression   or]  conjunction 
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conjunction     =     [conjunction   &  ]  [not]  relation 
relation     -     [simplex   relator  ]  simplex 
relator     =     {=|^|<|>|^|^} 
simplex     =     [simplex   {+  |  —  }]  term 
term     =     [term   {*  |  /    |   %)]  factor 
+ 


factor    = 


primary 


primary     =     primitive    [:  primary 
( 


primitive 


constant     — 


constant 
[own]  variable 
primitive    [arguments  \ 
(  expression    ) 

(expression   ,    •  •  •  | 

expression  append  expression) 

call 

rule  —denotation 
\ 

digit + 
(  char\ 


nil 


ru/c  —denotation     =     [the]  rules  {  compound  —  rule    .  }     end  rules 
dcterm     =    jan 

K 

noun     =     word  + 
verb     =     word  + 
adjective     -     u>ord  + 
preposition     =     word + 
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APPENDIX  E:    SYNTAX  OF  Q4 


Session     = 


statement  —list     = 


Dialog 


statement  —list 


1:  Qi  — statement  x 
2:  fts— statement 2 

n  :  fis-  statement,, 


compound  —  rule 


namel       else:    name7 


cause 


effect 


or 


name 


cause 


effect 


cause     =     condition* 
condition     = 


name     \  (modifier)  ] 


name  t:  pattern  , 
name,  :  patternn 


(If  the  field  names  are  first  and  rest,  then  the  pattern  matches  the  first  and  rest  of  an  arbitrary  tuple.) 

/delete  \ 
modifier     =    |absentJ 


pattern 


variable  \ 

fjj—  expression] 


effect    =     transaction 

I  nonsequential] 


transaction     = 


nonsequential     - 


sequential 


{kind ) 


name,:  Qi— expression  ^ 
namen:  fi8—  expressionn 


/delete         ^ 

kind     =    i  .        \ 

I  procedure/ 
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sequential    = 


Sequence 
statement  —list 


rule  —denotation     = 


Rules:    name 


name 


name. 
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APPENDIX  F:   INCOMPATIBILITIES  WITH  MCARTHUR  PROTOTYPE 

There  are  a  number  of  minor  syntactic  incompatibilities  between  the  dialect  of  ftj  implemented  by  the 
McArthur  prototype  and  that  described  in  this  report. 

1.  To  simplify  parsing,  the  keyword  if  is  required  on  all  rules  with  a  n  on  null  cause. 

2.  The  lexical  representation  of  '=>'  is  '->',  and  strings  are  surrounded  by  the  ASCII  double  quote  sym- 
bol. 

3.  Additional  degenerate  forms  of  rules,  such  as  'if  cause   =*',  are  permitted. 

4.  A  user  can  enter  multiple  sessions,  each  terminated  by  a  period.  The  period  calls  for  the  execution  of 
all  statements  in  that  session.  The  semicolon  statement  termination  does  not  cause  execution. 
Rather,  the  statements  are  saved  until  the  next  period. 

5.  The  McArthur  prototype  does  not  distinguish  between  statements  and  compound  rules.  The  result  is 
that  it  is  possible  to  activate  rules  with  an  empty  cause  part. 

6.  Arbitrary  expressions  are  permitted  as  transactions. 

7.  The  object-oriented  language  ft  is  augmented  with  an  applicative  sublanguage.  To  support  this, 
statements  include  function  declarations  of  the  form: 

function  variable    \  formats    ]  :  compound  —  expression 

where 


(variable    ,    •  •  •        \ 
LI  ■    LI 

variable    :  variable! 


and 


compound  —  expression     =     cond  -  expression  else    ■  •  ■ 
cond  -  expression     -     [if  expression   =*]  expression 

8.    Mutually  recursive  functions  are  declared  by  means  of  a  "forward"  declaration: 

function  /    |    •  •  •    j:  nil; 
function  g  [•■•]:■■•    /     •  •  •  ; 
function  /    |     ■•■];•••    g     •  •  •  ; 

This  ensures  that  /    is  bound  before  it's  used  in  g  ,  and  that  g  is  bound  before  it's  used  in  / 
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